Packets of data in a computer network typically contain information stored in protocol header fields corresponding to the various protocols that form the protocol stack for that packet of data. A protocol stack is a set of network protocols that work together so that two or more computers or other devices can communicate across a network. The different protocols that form a protocol stack frequently occupy different “layers” in the Open System Interconnection (OSI) Model. A commonly used protocol stack consists of the HyperText Transfer Protocol (HTTP), Transmission Control Protocol (TCP), Internet Protocol (IP) and Ethernet protocols.
A network processor in a network device will typically determine which network operation to perform on a packet of data by either executing software or by addressing fixed function hardware that addresses one or more lookup tables. A common technique, especially when using fixed function hardware, is to use a content-addressable memory (CAM) to allow only fields of interest in a fixed portion of the protocol header fields to be examined and acted upon. Whether a CAM is used or not, typically only a subset of the protocol header fields in the packet of data is utilized in making the determination. The particular protocol header fields that form this subset vary with the network environment and with the network device user. For example, a specific network device user may wish that fields in the Asynchronous Transfer Mode (ATM) Protocol, TCP, IP and Ethernet protocols be utilized to determine how to properly forward the packet of data to the next network device. A different network device user may wish to utilize an entirely different set of protocol header fields. As a result, it is frequently desirable to tailor the network device's software or associated CAM to match the network device user's specific application.
Notwithstanding this, such user-specific tailoring remains problematic. For example, programming network device software specifically for a network device user's particular application may be expensive. Moreover, such user-specific software programming lacks flexibility since the protocol header fields to be examined are fixed at the time the device software is written. As a result, most device manufacturers supply the same software to multiple network device users rather than attempt customization. This multi-user software will examine the union of what individual network device users may be interested in examining rather than addressing the particular needs of the specific network device user. Consequently, this software may examine many protocol header fields that are not of interest to a particular network device user while skipping over those that are of interest.
Likewise, using an external CAM to provide packet classification flexibility is also a limited solution. The cost of a CAM is largely a function of its table storage capacity. A CAM capable of storing a table of sufficient width and size to examine all the protocol header fields of interest to a specific network device user is, as a result, frequently too expensive to be practical.
For these reasons, there is a need for methods and apparatus allowing a network device to be easily and cost-effectively tailored by the network device user to perform network operations on packets of data in response to the content of particular user-specified protocol header fields.
A related patent application is U.S. patent application Ser. No. 11/263,300, entitled “Circuitry for Determining Network Operations in a Network Device” (filed Oct. 31, 2005), which is incorporated herein by reference.